Mobile IP (MIP) allows a mobile node to change its point of attachment to the Internet with minimal service disruption. MIP in itself does not provide any specific support for mobility across different administrative domains, which limits the applicability of MIP in a large-scale commercial deployment.
The MIP version 6 (MIPv6) protocol [1] allows nodes to move within the Internet topology while maintaining reachability and on-going connections with correspondent nodes. In this context, each mobile node is always identified by its home address, regardless of its current point of attachment to the IPv6 Internet. While situated away from its home network, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to the mobile node's home address are more or less transparently routed to its care-of address. The MIPv6 protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and then send any packets destined for the mobile node to the care-of address. To this end, the mobile node sends so-called binding updates to its home agent (HA) and the correspondent nodes with which it is communicating every time it moves.
MIPv6 capable mobile nodes, such as cellular phones, laptops and other end-user equipment, can thus roam between networks that belong to their home service provider as well as others. Roaming in foreign networks is enabled as a result of the service level and roaming agreements that exist between operators. MIPv6 provides session continuity within a single administrative domain, but depends on the availability of an Authentication, Authorization and Accounting (AAA) infrastructure to provide its services across different administrative domains, i.e. when roaming outside the network administered by the home operator. One of the key AAA protocols that contribute to making this kind of a roaming mechanism possible is Diameter.
In addition, although Mobile IPv6 can be regarded as a complete mobility protocol, more and/or improved mechanisms that facilitate deployment of MIPv6 are still needed in order to enable large-scale deployment. Although these mechanisms would not be part of the actual MIPv6 protocol, efficient deployment of MIPv6 services would heavily depend on them. The deployment related mechanisms would deal with issues such as the initial configuration of a MIPv6 enabled mobile node (MN), including configuration data such as the home network prefix or the home address, the home agent address, and the required IPsec SAs or security parameters on which dynamically established IPsec SAs can be based. One approach for the deployment related mechanisms is to leverage the existing AAA infrastructure.
In [2], for example, attempts are made to specify a new application to Diameter facilitating MIPv6 roaming in networks other than the home domain. This document identifies information that typically needs to be exchanged between a MN and an AAA Client in the network—MIP Feature Data, EAP Data, Security Key Data, and Embedded Data. It also proposes use of the new Diameter application in exchanges of this information between AAA Client and AAAv (the visited AAA server), between AAAv and AAAh (the home AAA server) and between HA and the AAA infrastructure. Although [2] does not specify any particular mechanism for communication between the mobile node and the AAA Client, the possibility to use the PANA protocol [3] is mentioned. However, the PANA WG has defined the scope of PANA such that it would not be able to transport the mentioned MIPv6-related information, which makes this solution unsatisfactory and non-complete.
Another drawback of the solution in [2] is that it requires the AAA Client (and AAAv) to understand the authentication method and be aware of the contents of the exchanges (MIP Feature Data, EAP Data, Security Key Data, and Embedded Data) between the MN and the AAAh. With such a solution it is not possible to apply prior encryption between MN and AAAh and the exchanges will be visible over the air interface. Security against eavesdropping, man-in-the-middle and other attacks is likely to be compromised.
Yet another drawback of the solution in [2] is that it requires support for the mechanisms both in the access network and in the AAAv. This may hamper deployment of the solution, since an operator that wants to use it depends on roaming partners to upgrade their networks to support the solution.
Accordingly, conventional mobility solutions are associated with several drawbacks and the need for a satisfactory mechanism supporting MIPv6 remains.